In a software system, a feature is an increment of functionality, usually with a coherent purpose. A feature is normally described from a user's perspective and may be described in a natural language format, but is more normally presented in the form of a formal language specification that is representative of software code often written in a source language such as C, C++, C# or Java. The code, when executed in a processor of a data processing device, implements said feature.
Typical software design methodologies using source languages such as C. C++ or Java suffer from a number of problems that cause high labor costs, poor quality and unpredictable completion scheduling of complex software projects. These problems include incomplete capture of feature requirements using prose-based descriptions of feature operations that do not cover every possible scenario and event. Also, feature interactions for complex systems grow at an exponential rate that makes complete feature definition impracticable using traditional feature definition specification documentation. However, without a complete feature specification, the eventual operation of the software is left open to subjective interpretations of the designer(s) and may not be formally captured outside of the implied operation of the code itself. A further problem is that the addition of new features using source code changes creates a risk that existing features may no longer work as previously. The manual methods of defect avoidance such as code inspection and regression testing reduce this risk but do not eliminate the possibility of new defects in old features.
In the field of telecommunications, features software became possible in the 1960s, with the advent of computer-controlled telephone switches. Telecommunication software has been conceived in terms of features ever since. Features may be optional, so that different users of data processing devices such as telephones can subscribe to the features they require or desire. Many features can be enabled or disabled dynamically by their subscribers. The provision of new or enhanced features is an important differentiator between telecommunication service providers and an important source of revenue over and above revenues generated by basic call services.
Utilizing features software is popular because it makes it easy to add and change features. However, an ever demanding problem exists in the form of unwanted features interactions and how to test for these and resolve them. It should be noted that not all features interactions are undesirable, but the emphasis is naturally on dealing with unwanted interactions since these can have unexpected consequences that may threaten the integrity of a vendor's product.
Consider, for example, a Private Branch Exchange “PBX”. The feature set of a known PBX can amount to over 500 features, with more than 3 million lines of code implementing those features. The possible number of features interactions can be proportional to the product of 2 to the power of 500 (2500) so it is impractical to test for every possible features interaction because the time and expense of doing so using existing tools would be uneconomical, if not impossible. In most commercial situations, testing for and resolving features interactions is a compromise between on the one hand providing acceptable quality software and on the other hand time to market, cost of development and testing, etc.
A feature interaction is a special case that arises when two different features have a response to the same event or sequence of events. When such an event occurs the features should behave in one of three ways:
1) Overridden Response: The behavior of one feature overrides the behavior of the other. That is, one feature handles the event and the other feature acts as if it were disabled;
2) Concurrent Response: both features react to the event. That is, they act as if the other feature did not exist; and
3) Combined Response: the two features react in a combined fashion. That is, they have been arranged to react in a special way that is not merely a combination of their reactions when separately implemented.
If the features do not behave in one of these ways then one of the following bugs has occurred:
1) The incorrect feature or combination of features has responded to the event. For example, an option setting has been ignored/overlooked or a new feature or option is required;
2) The correct response occurred but the responding feature or combination of features was implemented incorrectly; and
3) A conflict arises—this can only occur in the case of a Concurrent Response. The two features have conflicting use for the same resource. That is, one feature uses some resource in a way that prevents the other feature from behaving as expected. One example would be acquiring access to a shared resource and not releasing it. A more specific example would be when one feature wants to turn on a light continuously on the device display while the other wants to have the light blink.
An example of a feature interaction in a PBX may comprise the interaction between say “Call Answer”—when a user does not answer an incoming call the caller is redirected to an answering service, where they can record a voice message for the user—and “Call Forward”—which allows a user to redirect (Forward) calls made to a particular phone number to another number. For example, the user could forward calls from his/her work extension to his/her mobile handset when away from the office. Clearly, these features are incompatible. Therefore, it is necessary to determine whether “Call Forwarding” should override “Call Answer” and then resolve the resultant determination. This feature interaction is simple to resolve since if “Call Forwarding” does not override “Call Answer” then it serves no useful purpose. Thus, the code for one or both of “Call forwarding” and “Call Answer” requires modification to ensure “Call forwarding”, when enabled, overrides “Call Answer”. However, dealing with a features interaction is not always as simple as selecting one feature over the other. Sometimes new functionality needs to be introduced to accommodate the desired behavior.
A features interaction therefore is some way in which a feature or features modify or influence another feature in defining overall system behavior. Features interactions are especially common in telecommunications, because all features are modifying or enhancing the same basic service, i.e. the plain old telephone service (POTS). However, the features interaction problem is not limited to circuit switched legacy networks. New packet based telecommunications networks which are feature rich have a complexity that far outstrips that ever implemented in circuit switched systems and so the features interaction problem is a continuing and ever expanding one.
Historically, developers of telecommunication software have had no effective means of understanding and managing all features interactions. As a result, features interactions have been a notorious source of runaway complexity, software bugs, cost and schedule overruns, and unfortunate user experiences. Further, the problem of features interactions is no longer only a concern in the development of features software in the field of telecommunications but also now for developers of software systems in other fields.